Field of the Invention
The present application relates to security policies within a computing system, and more particularly to a method and system for managing security policies within an information technology (IT) system.
Description of Background Art
It is often difficult to manage security policies within a computing system. Numerous factors introduce complexities: Firstly, the IT environment is getting increasingly complex, with today's agile (i.e. dynamically changing), complex, interconnected Systems of Systems (SoS). Examples include Internet of Things (IoT), Machine-to-Machine (M2M), Service Oriented Architectures (SOA), Cloud computing. At the same time, some of these IT landscapes directly impact safety and security critical in the real (i.e. physical) world, rather than just being relevant to information collected/stored/processed. Information flowing through those systems needs to be protected, which is a highly complex endeavor. As a consequence, security needs to become more effective and reliable. Secondly, security policies need to capture increasingly more complex security requirements that are meaningful to business, and are often driven by compliance/accreditation requirements. Features of such advanced policies are that they involve policy rules that are numerous, complex, feature-rich (e.g. privacy), fine-grained, contextual/dynamic etc.
Most of the current status quo of security technologies fails to meet those requirements (i.e. to support today's IT landscapes and the management/enforcement of adequate security policies). “Blacklisting” and other approaches that focus on detecting and blocking/mitigating unwelcomed contents and access cannot implement the required security policies. On the other hand, “whitelisting” and other approaches that focus on only allowing appropriate contents and access are unmanageable using today's manual policy implementation approaches.
The world needs better policy management methods and systems that can manage meaningful policies, which are preventive (whitelisting), in a way that is manageable, and that supports IT agility, and that is repeatable/traceable/verifiable. US Patent Application Publication No. US 2009/0077621 to Lang et al. (“Method and system for managing security policies”, which is incorporated by reference herein for its entirety, thereafter called “MDS patent”) proposes security policies that include access permissions between different applications or programs, between applications and files, between users and applications and/or files and other access control functionality at various layers of the application or network (e.g., IP packet filters, middleware layer access control, application layer access control, information filtering), between Quality of Protection policies for confidentiality and integrity of communication using encryption or secure hash functions, or between security policies enforced within the application itself, e.g. at the generation of sets or subsets of data.
Furthermore, as explained in US Patent Application Publication No. US 2011/0093916 to Lang et al. (“Method and system for rapid accreditation/re-accreditation of agile it environments, for example service oriented architecture (soa)”, which is incorporated by reference herein for its entirety, thereafter called “MDSA patent”), conventional accreditation methods (such as Common Criteria) are also inadequate for today's agile SoS, because they require too much manual effort, and also usually require a static SoS to be verified.
US Patent Application Publication No. US 2009/0077621 (and US Patent Application Publication No. US 2011/0093916) explains how a “model-driven security” (MDS) approach can be used to better manage security policies, i.e. to meet (some of) the abovementioned requirements.
However, while US Patent Application Publication No. US 2009/0077621 (and US Patent Application Publication No. US 2011/0093916) describes a broad set of embodiments for the method and system that can meet the abovementioned requirements, it is possible to implement various embodiments that can be further improved.
The below section introduces various subject areas that form relevant background for the present application.
Attribute-Based Access Control
The NIST 800-162 draft (“NIST Special Publication 800-162. Guide to Attribute Based Access Control (ABAC) Definition and Considerations (Draft)”, 2013) defines Attribute-Based Access Control (ABAC) as “a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.”
In other words, ABAC uses attributes to describe all the entities considered for access control, and access control rules that describe access requests using attribute key-value pairs (or key-value-value triples in PBAC, as explained below) and associated calculation functions (e.g. equal, subset, less, greater, subset, relationship/distance/proximity etc.). In yet other words, attributes associated with a subject, context, action or resource are inputs into the decision of whether that subject may access a given resource in a particular way. And in yet other words, ABAC determines access (i.e., operations upon system objects) by matching the current value of subject attributes, object attributes, and environment conditions with the requirements specified in access control rules.
Policy rules and attributes are parts of ABAC. In ABAC, policy is the representation of rules or relationships that define (by comparing fetched attributes values with values stated in the policy, based on a calculation function) the set of allowable operations (actions) a subject may perform upon an object in permitted environment conditions. Policy rules specify which combinations of calculation results of attributes (types and values) of subjects, objects, operations (actions) and context will result in granting or denying a subject to execute an operation on an object in the given context.
An operation (action) is the execution of a function at the request of a subject upon an object (e.g. invoke, read, write, edit, delete, author, copy, execute, modify, etc.)
Attributes are characteristics that define specific aspects of the subject, object, environment conditions, and/or requested actions that are predefined and pre-assigned by an authority.
A subject is an active entity (generally an individual, process, or device) that causes information to flow among objects or changes the system state.
An object is a passive information system-related entity (e.g., devices, files, records, tables, processes, programs, networks, domains) containing or receiving information.
Context (environmental conditions) are dynamic factors, independent of subject and object, that may be used as attributes at decision time to influence an access decision (e.g. time, location, threat level, temperature, etc.)
Model-Driven Security (MDS)
This section presents an embodiment of model-driven security (MDS) as previously described in US 20090077621 A1.
Model-driven security is needed (and/or ABAC, RBAC etc.) for many systems because it: Simplifies policy authoring; makes policies more generic, human-understandable; reduces the gap between enterprise security policy and technical implementation; automates technical policy creation; reuses information from other stakeholders/sources; improves auditing and accreditation; reduces maintenance complexity; enables rule/attribute interoperability; and is based on proven model-driven concepts.
This model-driven security (“MDS”) is used for policy automation (top-down), while the use of model-driven security for accreditation automation (bottom-up) is called “MDSA” and is described further below. The combination could be described as “security policy roundtrip engineering”.
Model-driven security originates from research work since 2002 and is related to the well-accepted concepts of the OMG Model Driven Architecture (MDA). As an example implementation, full model-driven security has been implemented by the authors since 2002 in their OpenPMF product, which uses model-driven approaches (i.e. the top-down MDS part) to automate the process of translating human-understandable security & compliance requirements into the corresponding numerous and ever-changing technical authorization policy rules and configurations. This model-driven security policy automation approach forms for example a critical part of an effective least privilege implementation for agile IT landscapes.
MDS provides the means to specify security intent in some “undistorted” model and then use some kind of automatic (tool-supported) process to arrive (“top-down”) at a protected IT landscape. The original term used by ObjectSecurity for this is “model-driven security” (“MDS”). In other words, MDS transforms “undistorted” security policy models into the matching technical security implementation, esp. machine-enforceable access rules (and other policies).
Model driven security policy automation (“MDS”) can be defined as follows: MDS is the tool supported process of modelling security requirements at a high level of abstraction, and using other information sources available about the system (ideally produced by other stakeholders). These inputs, which are expressed in Domain Specific Languages (DSL), are then transformed into enforceable security rules with as little human intervention as possible. MDS explicitly also includes the run-time security management (e.g. ABAC based), i.e. run-time enforcement of the policy on the protected IT systems, dynamic policy updates and the monitoring of policy violations.
FIG. 1 illustrates a general MDS approach in summary. The figure illustrates “model-driven security (MDS) policy automation” at a high abstraction level. A model-driven development process (including an application model 140, model transformations 150, and running applications 160) is depicted in the right half of the figure. Application Models (140), including application interactions, may be modelled using one of e.g.:
1) Model-driven service orchestration (or similar MDD) tools, which basically allow application modules to be “plugged together” in a drag-and-drop and plug-and-play fashion. The actual application is the integrated orchestration of those modules. The model-driven orchestration tool automatically deploys and integrates the modules as modelled; and
2) Middleware/asset/network mapping tools and the like can be used to automatically detect and generate a system description from the IT landscape.
The Model Transformations (150) generate the software (or interaction orchestration etc.) that matches the specification in the Application Model (140). This software is then executed at runtime, e.g. Running Applications (160).
The resulting application/system model provides valuable, reliable information about the application with its interactions to the model-driven security process, including a security metamodel or meta-model (metamodeling or meta-modeling) 110, a security model 111, a security (policy-generation) workflow (model transformation) 120, security rules 130, and enforcement points 170. It works as follows:
The first step of model-driven security policy automation involves metamodeling (110) and modeling (111) the features of the security policy using a Domain-Specific Language (DSL).
After that security policy can be modelled in the security model (111) using features specified in the metamodeled DSL. If necessary the policy-generation workflow (120) can be customized.
After that, in some implementations, the model-driven security component enforcement points (170) are installed into the runtime platforms that host the applications (160).
The model-driven security workflow (120) can then be executed to automatically generate fine-grained contextual technical security rules (130), taking into account various system and context information, including the application model (140) used to build the running applications (160) using model transformations (150).
Inputs: Examples of MDS inputs are:
(1) Functional inputs, which provide useful information sources about the system that needs to be protected include for example: Service/component models/metamodels, service interaction models/metamodels, workflow models/metamodels, deployment models/metamodels, asset/network mapper tool feeds, Enterprise Architecture Framework models/metamodels, software source code, manual inputs, attributes information sources etc. It is also possible to combine various inputs into the same model (e.g. role tags in class diagrams or context policies in BPMN), or separate input models for security and system functionality can be provided;
(2) Security inputs, such as for example: Security policy and privacy models, and metamodels, security tags in (functional) models, hand-coded policy rules (in a policy editor), security attribute information from Policy Information Points (PIPs) etc.; and
(3) Other non-functional inputs, for example about Quality of Service (QoS)
Transformations: MDS model transformations turn the inputs into the outputs. A trivial policy example would be “Interactions in the component deployment model are interpreted as explicit granted access”. Roles are only used to split up interfaces into subsets of operations, in order to minimize privileges. From these transformation inputs, MDS then generates a number of explicit access rules that allows the identity of the modelled invoker to access the modelled invocation target. The advantage of this approach is that basic security policies for distributed component applications can be automatically generated without any human interaction or any security-related tags in the models. OpenPMF MDS model transformations use rule templates (implemented in Eclipse, which includes a modelling framework that can be used for transformations, including for example EMF, OAW, MWE, Xtext, Xpand etc.) It is important to see that the customer who uses the MDS tool (in this case OpenPMF) will not see any of the model transformation complexity once the MDS tool is installed and configured. All they will see is a development/modelling GUI with some extra features and menu items for the model transformation.
Output: The MDS output is a number of technical security rules (e.g. ABAC rules, RBAC configuration files or IP layer filter lists) and other configuration files (e.g. command lines for application start up) for all parts of the application and security infrastructure that reflect the high-level input security requirements at a low level of abstraction and that can be enforced or implemented within the actual system.
The technical security rules are then automatically pushed into the policy enforcement points for enforcement, and policy incidents are monitored.
Whenever applications change (esp. the integration), the technical security rules can be automatically re-generated.
MDS has a number of benefits when used correctly, including: reduces manual administration, reduces security risks, increases assurance, simplifies/automates policy authoring & maintenance, reduces the gap between enterprise security/privacy policy and technical implementation, helps save cost, IT agility, reduces complexity, supports rich application security policies, and more.
Model-Driven Security Accreditation (MDSA) (Enforcement-to-Model Verification)
This section presents an embodiment of model-driven security (MDS) as previously described in US Patent Application Publication No. US 2011/0093916 A1, which is incorporated into the present application by reference.
The purpose of this model-driven security approach is to correlate the inverse direction (“bottom-up”), where “undistorted” models are specified for checking, verification and/or compliance, certification & accreditation purposes: The correspondence between security characteristics of the actual IT landscape with the specified compliance/accreditation models is verified. The original term used by ObjectSecurity for this is “model-driven security accreditation” (“MDSA”). In other words, MDSA analyses and documents the traceable correspondence between technical security implementation, security policy models, and “undistorted” accreditation models.
Model-Driven Security Accreditation Automation (“MDSA”) automates the analysis of traceable correspondence between technical security policy implementation (e.g. ABAC) and the information assurance requirements captured in “undistorted” requirements models (e.g. Common Criteria, control objectives). MDSA also documents “supporting evidence” for accreditation based on various information (esp. design-time system/security models, system/security artefacts, system/security model transformations, and runtime system/security incident logs). Furthermore, MDSA enables the automated change detection and analysis to determine whether the accreditation is still valid. MDSA also acts as a decision support tool.
FIG. 2 illustrates general MDSA implementation by ObjectSecurity. The figure illustrates “model-driven security accreditation (MDSA) automation” at a conceptual level. The model-driven application integration process is again depicted on the right side of the figure, which includes an application model 240, model transformations 250, and running applications 260, analogous to the application 140, model transformations 150, and running applications 160, and the “model-driven security policy automation” process, which was described in the previous section is depicted on the left side of the figure, which includes security metal-model 210, security model 211, security workflow (model transformations) 220, (security rules) 230, enforcement points 270 (analogous to security metamodel 110, security model 111, security workflow (model transformations) 120, security rules 130, enforcement points 170 in FIG. 1). The MDSA process, which includes accreditation metamodel 280, accreditation model 285, accreditation workflow (model transformations) 290, and accreditation evidence report 295, is the difference from the MDS approach shown in FIG. 1:
The first step of MDSA involves metamodeling (280) the features of the accreditation model in a Domain Specific Language (DSL), and then and modelling (285) the accreditation (or compliance) requirements using that DSL. If necessary the “accreditation/compliance supporting evidence” generation workflow (290) can be customized.
After that, the model-driven accreditation workflow (290) is executed to automatically generate an accreditation/compliance supporting evidence report (295). The workflow basically reads, analyses and correlates information from the various models (system integration model, the security policy requirements model/metamodel, the accreditation/compliance requirements model/metamodel), various workflows (application generation, policy rule generation, and its own evidence generator), various outputs (information about integrated running applications, incidents, generated policy rules etc.), as well as system and context information.
The automatically generated output is a full correlation analysis of all the analyzed inputs, to either help demonstrate accreditation/compliance, or to point out flaws/vulnerabilities/errors etc.
One feature of MDSA is that whenever applications or security policies change, the accreditation/compliance evidence report can be automatically re-generated and compared for differences (based on change policies that specify allowable change paths).
MDSA was originally invented for automating large parts of the compliance and assurance accreditation management processes (e.g. Common Criteria) to achieve reduced cost/effort, and increased reliability/traceability. MDSA automatically analyses and documents two main compliance aspects including whether or the actual security of the “system of systems” at any given point match with the stated requirements (correspondence analysis), and whether or not any changes to the system of systems impact the current accreditation (change analysis).
MDSA has a number of benefits, including: enabling agile/shortened accreditation of policies & enforcement (PBAC, ABAC, RBAC etc.), cost savings, automation, traceability etc. MDSA's potential challenges & Considerations include the (now) blurred boundaries between design & accreditation time vs. runtime, resistance to change, political challenges, training requirements etc.
Proximity-Based Access Control (PBAC)
In PBAC, proximity in general includes the following general concepts:
The proximity aspect (attributes) considered, which is the attribute(s) used to express proximity. For example, time, place, causation, influence, order, occurrence, or relation. A critical requirement for proximity attributes is that they are within a space where a notion of distance exists.
The distance function between two or more proximity attributes. In mathematics, a metric or distance function is a function that defines a distance between elements of a set. A set with a metric is called a metric space. A metric induces a topology on a set but not all topologies can be generated by a metric. A topological space whose topology can be described by a metric is called “metrizable”. Graphs and graph theory can also be used to describe distances (e.g. number of hops across a directed graph).
PBAC is defined as an approach where information provided to a subject is determined need-to-know based on proximity attributes. It is an access control mechanism that will dynamically adjust data access for individuals based on proximity profiles, i.e. their proximity to others, organizations, devices, and/or information in terms of attributes (e.g. location, mission, assignment) derived from existing sources. For example, the closer something/someone is in proximity to the requestor, the more important it is to that person and the more details the requestor will need about it. Access to information is granted to be need-to-know based on the proximity of a subject (user acting using a device, or a device acting on its own) to the requested information based on relevant criteria (“proximity attributes”). Proximity can be based on for example geo-location, spatial proximity (i.e., physical location), organizational proximity (e.g., relationships in the chain of command), operational proximity (e.g., supported/supporting units, common missions), social proximity, business process proximity etc. For example, a team leader for a first responder team responding to an accident may want to gain insight into data from other teams at a shared geographic area (spatial proximity) in order to increase logistical efficiencies, better understand what other teams are planning or doing (organizational proximity) in order to coordinate better, or obtain assessments and other information developed by a supported already-deployed team (operational proximity) in order to plan more effectively.
There are also two additional proximity-based access control approaches, which can be seen as subcategories of PBAC and can be implemented using PBAC:
(1) Proximity-Based Information Provisioning (“PBAC-IP”): This approach does not only determine access based on proximity, but additional inference is used to determine what information is most important based on proximity. This can help focus users' attention by inferring what might be useful based on the proximity profile. This is a useful side benefit in a highly dynamic environment. When implemented, PBAC-IP may result in information to be (1) pushed to users when relevant, (2) pushed to users when relevant if they previously subscribed to the information feed, or (3) determine the information released to the user when the user pulls information.
(2) Spatial Proximity-Based Device Access (“PBAC-DA”): In this approach, access to a device is granted based on the physical proximity of a subject (usually human users) to that device. This use case is discussed in depth in the academic literature (esp. in relation to RBAC) and seems to be the prevailing definition of PBAC in the academic literature. This PBAC use case is for example proposed for automatic granting of access to systems in a medical emergency room scenario, based on who is in proximity of a device.